
From Splitgraph's inception back in 2018, we have always been a Postgres-first company. Our serverless SQL API, `sgr`, the Splitgraph Data Delivery Network, the managed data platform &mdash; PostgreSQL and its rich ecosystem of extensions has been at the core of our products.

This is why we could not pass up the opportunity to join one of the top contributors to PostgreSQL. We are pleased to announce that Splitgraph has been acquired by [EDB](https://www.enterprisedb.com). The senior leadership at EDB is excited about our experience in OLAP and the modern data stack and believe that we will be a big part of their plans to grow the company.

From all of us at Splitgraph, thanks for being part of our journey these past five years. We can't wait to share more as we continue it under EDB's flag.

<center><ButtonLink href="https://www.enterprisedb.com/news/edb-acquires-splitgraph">Read the press release on EDB's website</ButtonLink></center>
<br/>


Splitgraph is joining EDB, the leader in accelerating Postgres in the enterprise.

EDB acquires Splitgraph


## What is Splitgraph?

Splitgraph is building the Unified Data Stack – an integrated and modern solution
for working with data without worrying about its infrastructure.

You can try Splitgraph now! Browse
[the public data catalog](https://www.splitgraph.com/explore) to discover
40,000+ repositories to query with SQL, through the
[web IDE](https://www.splitgraph.com/query)
or [any Postgres client](https://www.splitgraph.com/connect).

Splitgraph is powered by open standards and simple abstractions, like
[data images](https://www.splitgraph.com/docs/concepts/images) – immutable tables
that you can push and pull, or query on the fly.

## Push to the Data Delivery Network (DDN)

You can use the `sgr` command line client to build images from dozens of data
sources,
from [CSV files](https://www.splitgraph.com/docs/sgr-advanced/ingesting-data/load-csv-files)
to
[custom Foreign Data Wrappers](https://www.splitgraph.com/blog/foreign-data-wrappers).
To push them to the DDN, just run `sgr push`, like you would a Git branch or
Docker image.

Splitgraph helps data engineers work more like software engineers. But what if
you're not a data engineer? What if you just want to share a CSV file with
someone else, or query it with SQL, or join it with some other data?

That's why we built this feature – **drag and drop a CSV file** to upload it to
the Data Delivery Network, where you can publish it or share it privately. You
can even upload multiple, to create a table from each! (You can join across
those tables, too.)

## Upload, Share and Query CSV File(s)

Navigate to [`splitgraph.com/upload`](https://www.splitgraph.com/upload) to get
started,
or try it right from this blog post! Just upload the CSV file(s) you want
to publish as tables (privately or with anyone you share them with).

<EmbeddedUpload />

## Videos

Impatient? Watch these ten second clips demonstrating the feature.

### Upload one or multiple CSV files

<video width="100%" height="240" controls>
  <source src="/static-v2/demo-videos/upload-csv-files-demo.mp4" type="video/mp4" />
</video>

### Configure parameters

<video width="100%" height="240" controls>
  <source src="/static-v2/demo-videos/configure-csv-demo.mp4" type="video/mp4" />
</video>

### Invite collaborators by email

<video width="100%" height="240" controls>
  <source src="/static-v2/demo-videos/invite-user-demo.mp4" type="video/mp4" />
</video>

### Add collaborator by username

<video width="100%" height="240" controls>
  <source src="/static-v2/demo-videos/add-user-demo.mp4" type="video/mp4" />
</video>


## What's Next?

We've got a lot planned, and CSV uploads are just the tip of the iceberg. We're following a general theme of augmenting powerful command line tools
with a simple and intuitive web interface. You can already do much of this
from the CLI, but from the web you'll soon be able to:

- Connect to, or ingest from, hundreds of external data sources, all configurable via the web interface
- Create a [`splitgraph.yml`](https://www.splitgraph.com/docs/splitgraph.yml/introduction)
file from the web, and clone a GitHub repo to orchestrate scheduled ingestion of your data sources

## Want a private Splitgraph instance?

If you want Splitgraph for your internal company data,
then [join the private beta](https://www.splitgraph.com/join-beta) for our cloud
SaaS product. We can deploy a white-labeled instance to your own infrastructure
and setup a modern data stack for you without any hassle.



You can now upload CSV files to Splitgraph from the web, so that you can query them with SQL by pointing your Postgres client to the Data Delivery Network (DDN). Share data publicly or with only those you invite – all discoverable and queryable from a single unified interface.

Drag, drop and share CSV files as queryable SQL tables


Today, we are announcing the next step for Splitgraph: the [**Splitgraph Data Delivery Network**](https://www.splitgraph.com/connect).

The Splitgraph DDN is a single SQL endpoint that lets you query over 40,000 public datasets hosted on or proxied by Splitgraph.

You can connect to it from most PostgreSQL clients and BI tools **without having to install anything else**. It supports all read-only SQL constructs, including filters and aggregations. It even lets you run joins across distinct datasets.

In this post, we will give you a quick introduction to the DDN as well as discuss how it works behind the scenes and our plan for its future.

### Usage

#### Connecting

The endpoint is at `postgresql://data.splitgraph.com:5432/ddn`. You will need a Splitgraph API key and secret to access it.

You don't need to install anything to use the endpoint. If you go to your Splitgraph [account settings](https://www.splitgraph.com/connect), you can generate a pair of credentials. You can then plug them into your SQL client.

If you're already using the [`sgr` client](/docs/sgr-advanced/architecture/sgr-client) and had registered for Splitgraph before, you can check your `.sgconfig` file for the API keys. You can also upgrade your client to version 0.2.0 with `sgr upgrade` and run `sgr cloud sql` to get a libpq-compatible connection string.

[Installing Splitgraph locally](/docs/sgr-advanced/getting-started/installation) will let you snapshot these datasets and use them in [Splitfiles](/docs/sgr-advanced/concepts/splitfiles).

There are more setup methods available in [our documentation](/docs/query/ddn). This includes connecting to Splitgraph with clients like DBeaver, BI tools like Metabase or Google Data Studio or even other databases through ODBC.

#### Workspaces

When you connect to Splitgraph, your SQL client will show you some schemas. These are data repositories featured on our [explore page](/explore) as well as datasets that you upload to Splitgraph.

We call this feature "workspaces". It works by implementing the [ANSI information schema](https://en.wikipedia.org/wiki/Information_schema) standard. We'll expand on workspaces more in the future. For example, we'll let you:

  * bookmark repositories that you want to show up in your workspace
  * allow you to have multiple workspaces and manage access to them
  * search for Splitgraph repositories directly from your SQL client.

#### Running queries

You can run queries on Splitgraph images by referencing them as PostgreSQL schemata: `namespace/repository[:hash_or_tag]`. By default, we query the `latest` tag.

For example, if you want to query the [`cityofchicago/covid19-daily-cases-deaths-and-hospitalizations-naz8-j4nc` repository](https://www.splitgraph.com/cityofchicago/covid19-daily-cases-deaths-and-hospitalizations-naz8-j4nc), proxied by Splitgraph to [Socrata](https://data.cityofchicago.org/Health-Human-Services/COVID-19-Daily-Cases-and-Deaths/naz8-j4nc), you can run:

```sql
SELECT * FROM
	"cityofchicago/covid19-daily-cases-deaths-and-hospitalizations-naz8-j4nc".covid19_daily_cases_deaths_and_hospitalizations
```

We let you use SQL `SELECT` and `EXPLAIN` statements. You can use any SQL clauses, including group-bys, aggregations, filters and joins. Splitgraph pushes filters down to the origin data source.

This sample query that we used in our [Metabase demo](/docs/sgr-advanced/ingesting-data/socrata#using-metabase-to-join-and-plot-data-from-multiple-data-portals) runs a JOIN between two datasets:

```sql
SELECT
    cambridge_cases.date AS date,
    chicago_cases.cases_total AS chicago_daily_cases,
    cambridge_cases.new_positive_cases AS cambridge_daily_cases
FROM
    "cityofchicago/covid19-daily-cases-deaths-and-hospitalizations-naz8-j4nc".covid19_daily_cases_deaths_and_hospitalizations chicago_cases
FULL OUTER JOIN
    "cambridgema-gov/covid19-case-count-by-date-axxk-jvk8".covid19_case_count_by_date cambridge_cases
ON
    date_trunc('day', chicago_cases.lab_report_date) = cambridge_cases.date::timestamp
ORDER BY date ASC;
```

This will join the data between two distinct Socrata data portals ([Chicago, IL](https://data.cityofchicago.org/Health-Human-Services/COVID-19-Daily-Cases-Deaths-and-Hospitalizations/naz8-j4nc) and [Cambridge, MA](https://data.cambridgema.gov/Public-Safety/COVID-19-Cumulative-Cases-by-Date/tdt9-vq5y)).

![Splitgraph SQL endpoint JOIN query example](https://raw.githubusercontent.com/splitgraph/splitgraph.com/master/content/docs/0900_splitgraph-cloud/images/sql-endpoint/2-dbeaver-join.png)

We also support [PostGIS](https://postgis.net/), letting you query and visualize geospatial data. For example, you can query the [London ward boundary data](https://www.splitgraph.com/splitgraph/london_wards/) image as follows:

```sql
SELECT
    name,
    gss_code,
    -- Transform to https://epsg.io/4326 to plot on the map
    ST_Transform(ST_SetSRID(geom, 27700), 4326),
    -- Transform to https://epsg.io/3035 for metric units (for area)
    ST_Area(ST_Transform(ST_SetSRID(geom, 27700), 3035)) / 1000000 AS area_sqkm
FROM
    "splitgraph/london_wards".city_merged_2018
ORDER BY gss_code ASC;
```

![PostGIS data on Splitgraph DDN](https://raw.githubusercontent.com/splitgraph/splitgraph.com/master/content/docs/0900_splitgraph-cloud/images/sql-endpoint/3-dbeaver-geodata.png)

There are more sample queries on our [Connect page](https://www.splitgraph.com/connect).

### Behind the scenes

The Splitgraph Data Delivery Network is the result of all the work we've put into the [`sgr` client](/docs/sgr-advanced/architecture/sgr-client) and the [Splitgraph Core](https://github.com/splitgraph/sgr) code over the past two years.

It would also have not been possible without some other open source technologies.

We use PostgreSQL foreign data wrappers. They let us perform query execution and planning across federated data sources. We wrote about [foreign data wrappers](/blog/foreign-data-wrappers) before: they're powerful and underused!

We manage connections using a fork of [PgBouncer](https://www.pgbouncer.org), a PostgreSQL connection pooler. Our fork lets us perform authentication outside of PostgreSQL. We can issue and revoke API keys without having to manipulate database roles. Several inbound Splitgraph users can run queries as a single PostgreSQL user.

We also use PgBouncer to transform queries on the fly. We rewrite clients' introspection queries and let them reference Splitgraph images as PostgreSQL schemata.

Each client essentially operates within its own isolated virtual database. The obvious implementation of this would be spinning up one database per client. But our query transformations let us do this at a **much lower infrastructure cost**. We also use this feature to inspect and drop unwanted queries on the fly.

Finally, we use our own `sgr` client to orchestrate this. Splitgraph engines power the data delivery network. They manage foreign data wrapper instantiation and querying Splitgraph images via [layered querying](/docs/sgr-advanced/large-datasets/layered-querying). In the future, we will use Splitgraph's [storage format](/docs/sgr-advanced/concepts/objects) to snapshot remote datasets or cache frequent queries.

### Future and roadmap

There are a lot of directions we would like to pursue with Splitgraph.

You will be able to use Splitgraph to **replace some of your data lake or ETL pipelines** and query the data at source. This is similar to the idea of "data virtualization". But, unlike other software in this space, Splitgraph uses an open PostgreSQL protocol. This makes it immediately compatible with most of your BI tools and dashboards. It won't lock you into a proprietary query language.

We will soon have the ability to add [external repositories](/docs/add-data/data-sources/supported-modes) to public or on-premises Splitgraph data catalogs. You will be able to query any dataset indexed in this catalog over the single SQL endpoint or our [REST API](/docs/query/postgrest). You will be able to even use these datasets in [Splitfiles](/docs/sgr-advanced/concepts/splitfiles). This will let you define reproducible transformations on your data, enrich it with public datasets and track lineage.

You will be able to use Splitgraph as an **SQL firewall and a rewrite layer**. You won't need to use views to set up access policies for your data warehouse. Data consumers won't need to manage credentials to disjoint data silos. Splitgraph can inspect proxied queries and enforce granular access policies on individual columns. It will even be able to do PII masking and access auditing.

The single SQL endpoint is well suited for a **data marketplace**. Data vendors currently ship data in CSV files or other ad-hoc formats. They have to maintain pages of instructions on ingesting this data. With Splitgraph, data consumers will be able to acquire and interact with data directly from their applications and clients.

### Conclusion

Today, we launched the Splitgraph Data Delivery Network. It's a seamless experience of a single database with thousands of datasets at your fingertips, compatible with most existing clients and BI tools.

If you wish to try it out, you can get credentials to access it in less than a minute: just head on to the [landing page](https://www.splitgraph.com/connect).

We're also building towards a ["Splitgraph Private Cloud" product](/about/company/private-cloud-beta) that will let setup your own private Splitgraph cluster, managed by us and deployed to the cloud region of your choice. [Contact us](mailto:support@splitgraph.com) if you're interested!


We launch the Splitgraph Data Delivery Network: a single endpoint that lets any PostgreSQL application, client or BI tool to connect and query over 40,000 public datasets hosted or proxied by Splitgraph.

Port 5432 is open: introducing the Splitgraph Data Delivery Network


## Introduction

[Splitgraph](https://www.splitgraph.com) is a tool and platform for building, versioning, querying and sharing datasets. Inspired by Docker and Git, it works on top of PostgreSQL and integrates seamlessly with anything that uses PostgreSQL. Our [data catalog](https://www.splitgraph.com/explore) already includes over 40,000 datasets from government open data portals, all queryable via SQL.

The Splitgraph catalog classifies these datasets as [external repositories](/docs/add-data/data-sources/supported-modes). These are different from the default [Splitgraph repositories](/docs/concepts/repositories), which are collections of [Splitgraph images](/docs/concepts/images). Yet Splitgraph allows you to query them in the same way as you do Splitgraph images. For example, you can use SQL to query any repository or [`JOIN` between multiple of them](/docs/sgr-advanced/ingesting-data/socrata#using-metabase-to-join-and-plot-data-from-multiple-data-portals). Or you can use Splitfiles to [build reproducible datasets](/docs/sgr-advanced/ingesting-data/socrata#splitfile) from them. And every external repository includes an [auto-generated PostgREST API](/docs/query/postgrest).

External repositories allow Splitgraph Cloud to index live data without actually ingesting it. This way, you can use the catalog to discover live data. But you only need to ingest it when you're ready to query it, or snapshot it as part of a Splitgraph image.

## Data should be discoverable and composable

Many services exist for cataloging data and making it discoverable. For example, [Google Dataset Search](https://datasetsearch.research.google.com/) provides a nice interface for searching and discovering datasets (in fact, [it even includes Splitgraph repositories](https://datasetsearch.research.google.com/search?query=opd%20crimes&docid=jrM9a8yTUXMZaY1QAAAAAA%3D%3D)). The problem is, the data is fragmented and siloed across different data portals. It's nice to be able to search for data and download a CSV file. But most datasets are uninteresting in isolation. The real power comes from the ability to combine datasets and query them together.

Splitgraph does not only provide an index for discovering open data. It also provides the tools for composing open datasets together. For example, mounting the data from the [Cambridge](https://data.cambridgema.gov) and [Chicago](https://data.cityofchicago.org) data portals is as simple as running two commands:

```shell-session
$ sgr mount socrata chicago -o '{"domain": "data.cityofchicago.org"}'
Connecting to remote server...
Mounting Socrata domain...
Getting Socrata metadata
warning: Requests made without an app_token will be subject to strict throttling limits.
Loaded metadata for 504 Socrata tables

$ sgr mount socrata cambridge -o '{"domain": "data.cambridgema.gov"}'
Connecting to remote server...
Mounting Socrata domain...
Getting Socrata metadata
warning: Requests made without an app_token will be subject to strict throttling limits.
Loaded metadata for 137 Socrata tables
```

At this point, all the datasets in these two data portals are available for querying. You can query them in isolation, or you can query them together. You can use a Splitfile, `sgr sql`, or any standard SQL client:

[![DBeaver overview](https://raw.githubusercontent.com/splitgraph/splitgraph.com/master/content/docs/0300_ingesting-data/images/socrata/1_dbeaver_overview.png)](https://raw.githubusercontent.com/splitgraph/splitgraph.com/master/content/docs/0300_ingesting-data/images/socrata/1_dbeaver_overview.png)

Here's how you can compare daily COVID cases in Chicago and Cambridge (from two separate data portals) with a standard `JOIN` query:

```sql
SELECT
    cambridge_cases.date AS date,
    chicago_cases.cases_total AS chicago_daily_cases,
    cambridge_cases.new_positive_cases AS cambridge_daily_cases
FROM
    chicago.covid19_daily_cases_deaths_and_hospitalizations_naz8_j4nc chicago_cases
FULL OUTER JOIN
    cambridge.covid19_case_count_by_date_axxk_jvk8 cambridge_cases
ON
    date_trunc('day', chicago_cases.lab_report_date) = cambridge_cases.date::timestamp
ORDER BY date ASC;
```

(For more details and in-depth instructions, see the [Socrata FDW documentation](/docs/sgr-advanced/ingesting-data/socrata).)

Note that this is not limited to combining multiple public datasets. Often, the work of a data analyst includes combining internal data with public or licensed datasets from external vendors. The same semantics of "mounting" data in Splitgraph apply.

## Mounting vs. Cloning Data

With Splitgraph, there are two primary ways to ingest data: cloning it or mounting it.

["Cloning" (and checking-out)](/docs/sgr-advanced/working-with-data/clone-vs-checkout) an image means downloading a versioned data image, which is a snapshot of a database comprised of delta-compressed diffs. For example, the result of running a Splitfile is an image.

"Mounting" means establishing a connection to a live data source. The term comes from the idea of "mounting" a filesystem. A mounted table uses a [foreign data wrapper](/docs/sgr-advanced/ingesting-data/foreign-data-wrappers/introduction) (FDW), and you don't ingest data from it until you query it. For example, the [Socrata FDW](/docs/sgr-advanced/ingesting-data/socrata) translates SQL queries to [SoQL queries](https://dev.socrata.com/docs/queries/) and forwards them to the Socrata server.

(For more details on mounting data, FDWs and custom mount handlers, read our recent ["foreign data wrappers" blog post](/blog/foreign-data-wrappers).)

## Mounting data in Splitgraph Cloud

Mounting is the key abstraction that allows Splitgraph Cloud to index external repositories with features like an auto-generated REST API. On the backend, the "query API" (a subject for a later post) uses the Splitgraph library and Socrata mount handler to mount repositories on demand. Then it exposes the mounted schemata to a customized version of [PostgREST](http://postgrest.org/) which creates the API.

Separately, a periodic Airflow task queries the Socrata metadata API to discover and index over 40,000 repositories. Conveniently, the same Socrata software powers over 200 government open-data portals, so one mount handler provides a large catalog of useful live data.

## Avoiding the pull of Data Gravity

Mounting is a powerful abstraction because it allows you to interact directly with upstream data sources, avoiding the need for ETL. In 2010, GE Engineer Dave McCrory coined the term "[data gravity](https://datagravitas.com/2010/12/07/data-gravity-in-the-clouds/)." In his blog post, he observed that "data if large enough can be virtually impossible to move."

Splitgraph, as a data versioning solution, should work with all your data, not just the subsets of it that you can move. Traditional ETL tools force you to ingest or duplicate your data before you can interact with it. With Splitgraph, you only need to pull upstream data into your images at query time. This allows incremental adoption and quick experimentation; there is no need to move your data warehouse to start using Splitgraph. Instead, you only need to setup an FDW.

Note that the idea of data gravity applies to versioned data images (which you clone) as much as it does to upstream, live data (which you mount). What if you want to import only a subset of data from a large image? This is the use case for [layered querying](/docs/sgr-advanced/large-datasets/layered-querying), which allows you to "check out" an image without downloading it. Instead, Splitgraph creates an FDW that queries only the "layers" of the image necessary to satisfy the query. You can think of layered querying like a mount handler for Splitgraph images.

## Looking to the future

At the moment, Splitgraph Cloud only uses the [Socrata FDW](/docs/sgr-advanced/ingesting-data/socrata) as a mount handler for external repositories, since the [Socrata data platform](https://www.tylertech.com/products/socrata) powers most government open-data portals.  In the future, it could use additional mount handlers to provide access to a wider array of upstream sources. To create an external repository, Splitgraph just needs a suitable FDW and a way to index the upstream data. For example, it's easy to imagine indexing Google BigQuery datasets. More interestingly, an on-premise version of Splitgraph could index private databases or data warehouses behind a firewall.

Our goal for Splitgraph is to make tools for data science as easy and pleasurable to use as tools for coding. That's why our main philosophy is to "stay out of the way." Mounting data is a great example of this philosophy in action. Why force your data warehouse to talk to Splitgraph, when Splitgraph can talk to your data warehouse?

In the meantime, make sure to [explore data](/explore) on Splitgraph. If you know SQL, you can [get started](/docs/sgr-advanced/getting-started/five-minute-demo) in less than 10 minutes.


Learn about how Splitgraph indexes over 40,000 datasets from government and public sources using the Socrata API, Splitgraph mounting, and PostgreSQL foreign data wrappers.

Querying 40,000+ datasets with SQL


## Introduction

Splitgraph is a tool that makes working with data as easy as working with code. An oft-repeated trope is that data scientists spend 80% of their time cleaning data. This may not be strictly true, but certainly there is significant overhead for every deliverable. Software engineers have tools like Git and Docker that allow them to iterate and confidently deploy their code to production. For data scientists, the workflows in the experimentation phase are not nearly as productive. Too much effort is spent sourcing, cleaning and merging data together. And when it’s time to deploy a deliverable, it’s often impossible to keep it up to date without some sort of manual and brittle effort.

In a lot of ways, the domain of data science resembles system administration prior to the age of dev-ops and containerization. It used to be that every server was its own special snowflake, with brittle scripts holding it together and all sorts of failure modes when deploying new code. But “infrastructure-as-code” and technologies like Docker changed that for the better. We think that data science has similar problems. Whether you’re deploying ML models, generating reports, or building dashboards, maintaining them seems to require a lot of effort, and it seems like you’re repeating yourself every time you start a new project.

We’re building Splitgraph to address these problems. It’s inspired by Docker and Git, so its semantics and conventions should feel somewhat familiar. And it’s powered by Postgres, so it will work with nearly all your existing tools.

## Where does 80% of the time go?

When starry eyed graduates and machine learning PhDs join the workforce as “data scientists,” they dream of spending all day training neural networks on GPU clusters, and applying Gaussian processes and support vector machines to their company’s databases to unlock new sources of business value. Turns out, there’s a lot more grueling, repetitive work to do before any of that can happen. Questions start to arise, like:

- Which of these dozens of databases in the company warehouse has the data I need?
- How can I get this data into the form I need it?
- Where can I find some public data to augment this proprietary information?

When they finally manage to create something useful, a whole new set of questions arises:

- Where can I deploy my version of this data?
- How can my teammates pull my data and iterate on it?
- When the upstream data sources change, how do I keep my deliverable up to date?

Sometimes, the data scientist can’t even answer these questions, and needs to pass it off to a data _engineer_ instead, sort of like how developers used to need to send their code to a deployment team.

## What do we like about software engineering workflows?

Software engineering has a lot of concepts that have made software more pleasant to build and maintain. Years of pain have led developers to coalesce around common workflows for versioning, building, packaging and deploying code:

- **Versioning and revision control** allows for rapid experimentation and collaboration. Engineers can track and revert every change to code.
- **Package managers** put millions of libraries at your fingertips, and integrating them into your project is as simple as running a command
- Docker helps build your code into **self-contained images** in a common format that you can drop into any stack
- With “infrastructure as code,” software engineers can control the deployment, provisioning and scaling process with **repeatable, version-controlled definition files**

Finally, good tools that implement all of this **enhance existing abstractions without breaking them**. You don’t need to adopt a new filesystem or use a specialized IDE to version your code with Git. You can build Docker images without changing your code to work in Docker or recompiling it to use some special Docker system calls. Git and Docker are good tools because they _stay out of the way_ while still adding value.

## Introducing Splitgraph

Splitgraph aims to bring these ideas and concepts into data science.

Splitgraph makes it easy to package datasets into [**self-contained data images**](/docs/concepts/images) that you can combine, query, extend and share
with other Splitgraph instances.

[**Splitfiles**](/docs/sgr-advanced/concepts/splitfiles) give you a declarative language, inspired by Dockerfiles, for expressing data transformations in ordinary SQL familiar to any researcher or business analyst. You can reference other images, or even other databases, [with a simple `JOIN`](/docs/sgr-advanced/splitfiles/splitfile-sql).

When you build data with Splitfiles, you get [**provenance tracking**](/docs/sgr-advanced/working-with-data/inspecting-provenance) of the resulting data: it's possible to find out what sources went into every dataset and know when
to rebuild it if the sources ever change. You can easily integrate Splitgraph into your existing CI pipelines, to keep your data up-to-date and stay on top of changes to upstream sources.

Splitgraph images are also **version-controlled**, and you can manipulate them with Git-like operations
through a CLI. You can “check out” any image into a PostgreSQL schema and interact with it using
any PostgreSQL client. Splitgraph will capture your changes to the data, and then you can commit them as **delta-compressed changesets** that you can package into new images.

Finally, Splitgraph isn't opinionated and **doesn't break existing abstractions**. To any existing PostgreSQL
application, Splitgraph images are just another database. We have carefully designed Splitgraph to not break the
abstraction of a PostgreSQL table and wire protocol, because doing otherwise would mean throwing
away a vast existing ecosystem of applications, users, libraries and extensions. This means that
a lot of **tools that work with PostgreSQL work with Splitgraph out of the box**.

We collect examples of the most interesting ones on the [integrations page](/product/splitgraph/integrations).

## Conclusion

When we started building Splitgraph in 2018, there was nothing around that combined all these concepts
into one product. Things are beginning to change and a lot of interesting tools are getting released to help data work. However,
we still don't feel like any of them completely satisfy our vision. We list applications and services that
are most similar to Splitgraph on our [Frequently Asked Questions](/docs/sgr-advanced/getting-started/frequently-asked-questions) page.

Over the next few weeks, we will be publishing a series of posts that dive deeper into our philosophy,
how Splitgraph works internally and some example use cases for Splitgraph.

In the meantime, Splitgraph is fully functional and ready to use. Head on to our
[documentation](/docs/sgr-advanced/getting-started/introduction) page for installation instructions, check out
[possible use cases](/product/splitgraph/use-cases) or take a look at our [integrations page](/product/splitgraph/integrations) to see how Splitgraph can help you.


Announcing Splitgraph, a data versioning and management system that allows you to work with data like you work with code.

Splitgraph has been acquired by EDB! Read the blog post.

By Miles Richardson

EDB acquires Splitgraph

Drag, drop and share CSV files as queryable SQL tables

Port 5432 is open: introducing the Splitgraph Data Delivery Network

Querying 40,000+ datasets with SQL

Welcome to Splitgraph

Product

Support

Company

Splitgraph

Splitgraph has been acquired by EDB! Read the blog post.

By Miles Richardson

EDB acquires Splitgraph

Drag, drop and share CSV files as queryable SQL tables

Port 5432 is open: introducing the Splitgraph Data Delivery Network

Querying 40,000+ datasets with SQL

Welcome to Splitgraph

Product

Support

Company

Community

Splitgraph